This is the 2023 implementation that uses the SysCert model pattern.
A description video is available here: MDriven produce your own certificates and log in with JWT or Saml2
The central points are the model pattern:
Use the SysCert.ecomdl merge file to get this into your model.
This pattern allows you to:
- Generate your own certificates with your own CN name
- Import public key part of external certs
- Generate JWT tokens
- Generate SAML2 tokens
- Validate JWT tokens
- Validate SAML2 tokens
The text below is the older implementation we did in 2022 - to allow javascript clients with a JWT authenticate access to Rest-API's in the Turnkey Application
(This is still good and ok - but the new SysCert-based solution supersedes this and is more generic in every way.)
Normally you log into the Turnkey site manually - and the application has an auth-scheme set up, but if you want to allow API login with arbitrary jwt token via rest call - and if you want to verify a sent-in bearer token as valid concerning a set of criterias and if so, then accept the user... Read on.
On Turnkey rest commands, add an Authentication header with the value "Bearer yourjwttoken".
We will unpack the JWT. Try to find a SysExternalJWTDefinition object that matches on Kid (short for KeyIdentity) and Aud (short for Audience and this is an identifier specific to the login you did).
The JWT is similar to the older XML-based format SAML and SAML2.
If found, we will use the values from attributes Modulus and Exponent. (You must find these at the place your key was created - like maybe https://accounts.google.com/.well-known/openid-configuration. These always end with well-known/openid-configuration) to verify the validity of your key (we will check that it is a valid key by using the certificate details you provided in Modulus and Exponent). Among the claims, we will only check that it has not expired.)
Here are the keys for Azure AD: https://login.microsoftonline.com/common/discovery/v2.0/keys
If the key was valid and unexpired, we take the email field from the key - or name if the email is not present - and send it to the Method SysExternalJWTDefinition.AcceptAndTransformUserName(user:string;audience:String):string
SysExternalJWTDefinition.AcceptAndTransformUserName - you can do any additional cleanup of the name to make it match the pattern you have in SysUser.Email - or return an empty string if you do not want to allow this user access.
if we get a nonempty string from AcceptAndTransformUserName, we will look up (not create) a SysUser with this name - and we will mark the user as logged in (ie - a cookie will be placed in the header so that subsequent calls to Get/Post, etc will be logged in calls).
Letting external programs call you via Javascript will require you to configure Cors - read more here.
See also: Connecting javascript SinglePageApplications to Turnkey (SPA)